في أغسطس 2025 اكتشف باحثو Zscaler ThreatLabz حزمتين خبيثتين نُشرتا على Python Package Index (PyPI) باسمَي sisaws وsecmeasure. لم تستغلا ثغرة في Python أو اختراقًا موثقًا لبنية PyPI نفسها؛ بل اعتمدتا على جعل Package تبدو مفيدة أو قريبة من مشروع شرعي، ثم استخدام الثقة التي يمنحها المطور عادةً للاعتماديات البرمجية لإيصال Remote Access Trojan أطلق عليه الباحثون اسم SilentSync.
تكمن أهمية الحادثة في أن جهاز المطور ليس Endpoint عاديًا: قد يحتوي على Source Code ومفاتيح SSH وGit credentials وCloud tokens وصلاحيات نشر Packages. لذلك يمكن أن يبدأ الخطر بحزمة صغيرة ثم يتحول، إذا نجحت الإصابة وسُرقت بيانات اعتماد حساسة، إلى مشكلة أوسع في سلسلة توريد البرمجيات.
وبحلول 28 أغسطس 2026 لم تعد صفحات sisaws وsecmeasure متاحة كمشاريع على PyPI، لذلك يجب التعامل مع الواقعة كحملة موثقة من 2025 لا كدليل على أن الحزمتين نفسيهما ما زالتا قناة توزيع نشطة اليوم. مع ذلك، تبقى البيئات القديمة وCaches وArtifacts وصور الحاويات التي احتوت على نسخة سابقة نقاطًا تستحق الفحص إذا استُخدمت الحزمتان أثناء فترة ظهورهما.
ماذا حدث في حملة SilentSync؟
بحسب التحليل الأصلي لـZscaler ThreatLabz، رصد الباحثون الحزمتين في 4 أغسطس 2025. كانتا مرتبطتين ببيانات ناشر متشابهة وتؤديان في النهاية إلى تنزيل SilentSync، لكن كل واحدة استخدمت غطاءً مختلفًا.
| الحزمة | التمويه | الوظيفة المرتبطة بالتنفيذ الخبيث | الإصدارات التي وثقها الباحثون |
|---|---|---|---|
sisaws |
تقليد حزمة sisa الشرعية المرتبطة بواجهات SISA الأرجنتينية |
gen_token |
2.1.6 في 4 أغسطس 2025 |
secmeasure |
مكتبة تبدو مخصصة لتنظيف النصوص وإجراءات أمنية بسيطة | sanitize_input |
0.1.0 و0.1.1 في 3 أغسطس، ثم 0.1.2 في 4 أغسطس 2025 |
هذه نقطة مهمة لفهم الهجوم: مجرد وجود Package تحمل اسمًا معقولًا وتنفذ بعض الوظائف الحقيقية لا يعني أن بقية الكود آمن. إضافة وظائف سليمة قد تجعل المراجعة السطحية أكثر إقناعًا بينما تبقى وظيفة ضارة موجودة في مكان آخر.
كيف استخدمت sisaws أسلوب Typosquatting؟
استفادت sisaws من التشابه مع حزمة شرعية باسم sisa. الحزمة الأصلية تتعامل مع خدمات مرتبطة بنظام المعلومات الصحية الأرجنتيني SISA، بينما حاولت النسخة الخبيثة تقليد أجزاء من سلوكها، بما في ذلك التحقق من بعض المدخلات وإرجاع Responses تبدو منطقية.
هذا الأسلوب يُعرف عادةً باسم Typosquatting أو Package Impersonation: يختار المهاجم اسمًا قريبًا من مشروع حقيقي أو اسمًا يمكن أن يثبته المطور بالخطأ. ولهذا لا ينبغي أن يكون اسم الحزمة وحده هو معيار الثقة؛ من المهم التحقق من المشروع والناشر والـRepository وسجل الإصدارات قبل إدخال Dependency جديدة إلى بيئة حساسة.
هل كانت الإصابة تبدأ بمجرد تثبيت الحزمة؟
ليس وفق سلسلة التنفيذ التي وثقتها Zscaler. التحليل يوضح أن الوظيفة الخبيثة كانت تحتاج إلى أن تُستدعى حتى تبدأ مرحلة تنزيل الحمولة التالية. في sisaws ارتبط ذلك بوظيفة gen_token، وفي secmeasure بوظيفة sanitize_input.
هذا الفرق مهم أثناء Incident Response. العثور على اسم الحزمة في requirements.txt أو بيئة Python يثبت وجود Exposure يستحق التحقيق، لكنه لا يثبت وحده أن SilentSync نُفذت بالفعل على الجهاز. يجب البحث عن أدلة التنفيذ والسلوك اللاحق.
كيف انتقلت السلسلة من PyPI إلى SilentSync؟
عند تشغيل الوظيفة الخبيثة المناسبة، كان الكود يفك ترميز بيانات مخفية تكشف أمرًا يستخدم curl لجلب Script إضافي من Pastebin، ويحفظه باسم helper.py داخل مجلد مؤقت في Windows ثم يشغله بواسطة Python. هذا الـScript هو المرحلة التي تقود إلى SilentSync.
لا توجد هنا حاجة إلى استغلال Memory Corruption أو Zero-Day في Python. المسار يعتمد أساسًا على تنفيذ كود قدمته Dependency يثق بها المستخدم، وهو نموذج مختلف عن استغلال ثغرة في Interpreter أو نظام التشغيل.
وتتشابه هذه الفكرة مع مخاطر أخرى شهدتها مستودعات البرمجيات، مثل واقعة حزمة Postmark-MCP المزوّرة وسلسلة توريد npm: المستودع العام يسهل توزيع البرمجيات، لكنه لا يجعل كل Package منشورة موثوقة تلقائيًا.
ما هي SilentSync RAT؟
SilentSync هي Remote Access Trojan مكتوبة بـPython. تحليل ThreatLabz وثّق مجموعة من القدرات التي تجعلها أكثر من مجرد Remote Shell، أبرزها:
- تنفيذ أوامر عن بُعد.
- سرقة ملفات فردية أو مجلدات.
- ضغط محتويات قبل إخراجها من الجهاز.
- التقاط Screenshots.
- جمع بيانات من متصفحات الويب.
- الاتصال بخادم Command-and-Control عبر HTTP.
كان العميل يتصل دوريًا بخادم C2 للحصول على مهام وإرسال نتائجها، وهو ما يوفر أيضًا فرصة للكشف عبر Network Monitoring حتى عندما لا يلتقط برنامج الحماية الملف في لحظة دخوله الأولى.
ما البيانات التي استهدفتها من المتصفحات؟
وثق الباحثون وظيفة مخصصة لجمع بيانات ملفات المستخدم في Chrome وMicrosoft Edge وBrave وFirefox على Windows. وشملت البيانات المستهدفة:
- بيانات الاعتماد المحفوظة.
- Cookies.
- سجل التصفح.
- بيانات Autofill.
ولهذا فإن تغيير كلمة المرور وحده قد لا يكون إجراءً كافيًا بعد إثبات إصابة جهاز. إذا تمكن Infostealer أو RAT من الحصول على Session cookies أو Tokens أخرى، فمن الضروري أيضًا إبطال الجلسات النشطة وإعادة إصدار الأسرار التي ربما كانت موجودة على الجهاز.
Windows أم Linux وmacOS؟ توضيح مهم
ذكرت Zscaler أن سلسلة الحزمتين التي حللتها كانت تستهدف Windows. وفي الوقت نفسه احتوى كود SilentSync نفسه على آليات Persistence مخصصة لعدة أنظمة.
- في Windows يستخدم مفتاح
Runداخل Registry، باسمPyHelper. - في Linux يتضمن مسارًا يعتمد على
crontabو@reboot. - في macOS يتضمن إنشاء LaunchAgent باسم
com.apple.pyhelper.plist.
لذلك لا يصح تحويل عبارة «البرمجية مكتوبة بـPython» إلى استنتاج أن الحملة المرصودة أصابت الأنظمة الثلاثة. وجود كود متعدد المنصات داخل RAT شيء، وأن تكون طريقة التوزيع المرصودة قد شغلت ذلك الكود فعليًا على كل منصة شيء آخر.
كيف يمكن اكتشاف آثار SilentSync؟
لا ينبغي استخدام Indicator واحد لإعلان الإصابة بصورة قطعية، لكن جمع أكثر من إشارة يمكن أن يساعد فرق SOC وIncident Response على تضييق التحقيق. من الإشارات المرتبطة بالسلسلة التي حللتها ThreatLabz:
- وجود تاريخ لتثبيت
sisawsأوsecmeasureفي بيئة Python. - تشغيل Python بالتزامن مع تنزيل Script من Pastebin بواسطة
curl. - ظهور ملف
helper.pyداخل مجلدات Windows المؤقتة. - وجود قيمة Persistence باسم
PyHelperفي مفتاحHKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run. - وصول Process غير متوقع يعمل بـPython إلى ملفات Profiles الخاصة بالمتصفحات.
- إنشاء أرشيفات ZIP بالتزامن مع نشاط شبكي غير معتاد.
- اتصالات HTTP دورية إلى بنية C2 التي وثقتها Zscaler.
ينشر تقرير ThreatLabz أيضًا Hashes وعناوين Network IOCs الخاصة بالعينات التي جرى تحليلها. لكن IOCs القديمة يمكن أن تتغير أو تتوقف عن العمل، لذلك من الأفضل دمجها مع Behavioral Detection بدل الاعتماد على IP أو Hash واحد فقط.
ماذا تفعل إذا وجدت sisaws أو secmeasure في بيئتك؟
وجود الحزمة يستدعي التحقيق، لكن الاستجابة يجب أن تتناسب مع الأدلة الموجودة. لا تكتفِ بتنفيذ Uninstall ثم اعتبار الحادث منتهيًا.
- حدد نطاق التعرض: ابحث في Virtual Environments وLock files وCI/CD jobs وContainer images وCaches وأجهزة المطورين لمعرفة أين ظهرت الحزمة وأي إصدار استُخدم.
- تحقق من التنفيذ: راجع Process telemetry وEDR وCommand-line logs وسجلات الشبكة لمعرفة إن كانت الوظيفة الخبيثة قد استُدعيت وبدأ تنزيل المرحلة التالية.
- اعزل الجهاز عند وجود دليل على التنفيذ: إذا ظهرت آثار SilentSync أو C2 أو سرقة بيانات، تعامل مع Endpoint كحادث اختراق وليس مجرد Dependency غير مرغوبة.
- حافظ على الأدلة: اجمع السجلات والعمليات والملفات والاتصالات ذات الصلة قبل تنظيف الجهاز عندما تسمح إجراءات المؤسسة بذلك.
- راجع Credentials والأسرار: افترض أن الأسرار المتاحة للمستخدم أو الموجودة على جهاز المطور ربما أصبحت معرضة إذا ثبت تشغيل RAT.
- أبطل الجلسات: ألغِ Browser sessions وAPI tokens وGit أوCloud credentials ذات الصلة بدل الاكتفاء بتغيير كلمة مرور واحدة.
- ابحث عن الانتشار: استخدم IOCs والسلوكيات المكتشفة لفحص بقية أجهزة الفريق وBuild agents والبنية المرتبطة بها.
- أعد بناء البيئة النظيفة عند الحاجة: في إصابة مؤكدة، إعادة بناء Workstation أوبيئة التطوير من مصدر موثوق توفر ثقة أكبر من حذف Package والـPayload المرئيين فقط.
هذه الإجراءات جزء من مفهوم أوسع للاستجابة متعددة الطبقات؛ ويمكن الرجوع إلى أفضل ممارسات الأمن السيبراني لفهم دور إدارة الصلاحيات والمراقبة والاستجابة للحوادث وحماية نقاط النهاية في تقليل أثر الاختراق.
كيف تقلل مخاطر Packages الخبيثة في مشاريع Python؟
تحقق من هوية الحزمة قبل التثبيت
قارن اسم المشروع بالوثائق الرسمية والـRepository الذي يشير إليه المطور الأصلي. راجع Maintainers وتاريخ الإصدارات وروابط المشروع، خصوصًا عندما يكون الاسم قريبًا جدًا من مكتبة معروفة أو عندما تكون Package حديثة ولا تملك تاريخًا واضحًا.
لا تمنح بيئة التطوير أسرارًا أكثر مما تحتاج
تطبيق Least Privilege على Developer Workstations يقلل ما يمكن للبرمجية سرقته. تجنب الاحتفاظ بمفاتيح إنتاج طويلة العمر أو Cloud credentials واسعة الصلاحيات على جهاز يستخدم لتجربة Dependencies غير موثوقة.
استخدم Locking وHashes، لكن افهم حدودها
تساعد Lock files على تثبيت إصدارات محددة بدل ترك Dependency resolution يتغير دون ملاحظة. كما تدعم وثائق pip الخاصة بالتثبيت الآمن Hash-checking mode للتحقق من أن الملف المثبت يطابق الـHash المتوقع.
لكن الـHash لا يستطيع أن يخبرك أن Package خبيثة إذا كنت قد وافقت أصلًا على Hash الملف الخبيث نفسه. فائدته الأساسية هنا هي منع استبدال Artifact المتوقع بملف مختلف وتحسين قابلية تكرار عملية التثبيت، وليس إجراء Malware Analysis نيابةً عنك.
راجع الاعتماديات الجديدة كتغيير في الكود
إضافة Dependency جديدة يمكن أن تمنح كودًا خارجيًا القدرة على التنفيذ داخل بيئتك. لهذا ينبغي أن تمر تغييرات requirements أو pyproject.toml أوLock files بمراجعة مشابهة لمراجعة Source Code، خاصة في المشاريع التي تتعامل مع إنتاج أوبيانات حساسة.
اعزل التجارب غير الموثوقة
استخدم Virtual Environments أوContainers أوSandbox مخصصًا عند فحص Package غير معروفة، ولا تجعل بيئة الاختبار نفسها تحتوي تلقائيًا على مفاتيح GitHub وSSH وCloud وProduction.
راقب سلوك أدوات التطوير
Python وPowerShell وcurl أدوات شرعية، ولذلك فإن منعها بالكامل ليس حلًا عمليًا في معظم فرق التطوير. الأفضل مراقبة السياق: لماذا بدأ Python الاتصال بنطاق خارجي جديد؟ ولماذا تصل Dependency إلى Browser profiles؟ وهل عملية Build بدأت فجأة في إنشاء Archives أوتشغيل Scripts من مجلد مؤقت؟
كيف تبلغ عن Package خبيثة على PyPI؟
توضح سياسة PyPI الأمنية أن المستخدم المسجل يمكنه الإبلاغ عن مشروع مشتبه به من صفحة المشروع عبر خيار Report project as malware. ويطلب PyPI تقديم تفسير للمشكلة وأدلة على السلوك المشبوه، وتشمل الأمثلة المقبولة Typosquatting وData Exfiltration وObfuscation وCommand-and-Control.
كما يستطيع PyPI وضع مشروع أوRelease في Quarantine عند الاشتباه في نشاط خبيث؛ وعندها تصبح النسخة المعزولة غير قابلة للتثبيت بواسطة العملاء إلى أن يراجعها مسؤولو PyPI.
ما الدرس الأهم من SilentSync؟
SilentSync لم تحتج إلى اكتشاف ثغرة جديدة في Python حتى تصل إلى جهاز مطور. يكفي أن تصبح Dependency الخبيثة جزءًا من مسار العمل ثم يُنفذ الكود الذي تخفيه.
وهذا يجعل Software Supply Chain Security مسألة تتجاوز فحص الثغرات المعروفة. يجب التحقق من هوية الاعتمادية ومصدرها وسلوكها والصلاحيات التي تعمل بها، مع قدرة المؤسسة على اكتشاف التنفيذ غير الطبيعي والاستجابة له إذا تجاوزت Package مرحلة التثبيت.
وبالنسبة للمطور، معرفة Python نفسها مفيدة في قراءة ما تفعله Dependencies والـScripts بدل التعامل معها كصندوق أسود؛ وهو جانب عملي يتقاطع مع استخدام Python في مسارات الأمن السيبراني والتحليل والأتمتة الدفاعية.
الحادثة الموثقة في 2025 انتهت كقصة عن حزمتين محددتين، لكن الدرس أبقى من أسمائهما: المستودع الموثوق لا يجعل كل Artifact بداخله موثوقًا، وجهاز المطور يستحق مستوى حماية ومراقبة يتناسب مع الأسرار والصلاحيات التي يستطيع الوصول إليها.